Looks good to me. This may be a problem in process-based chemicals. But it seems to be important to the overall model, and I now know that it's there, so we can either live with it, or find a solution for this implementation and chemicals-feedstocks-related SE differences to live alongside each other. Maybe I'll approach you for that in the coming months.

On an unrelated note:
From the documentation, I'd guess that
$\text{sqSectorShare}=\sum_{i=1}^n s_i^2\quad$ with the shares $s_i$ and $\quad\sum_{i=1}^n s_i=1,\quad$ and
$\text{sqSectorAvrgShare}=\sum_{i=1}^n (s_i-\bar{s_i})^2=\sum_{i=1}^n (s_i-\frac{1}{n})^2=\sum_{i=1}^n (s_i^2-\frac{2}{n}s_i+\frac{1}{n^2})=\text{sqSectorShare}-\frac{2}{n}+\frac{1}{n}$,
so they'd only differ by a constant, which shouldn't make a difference to the solver.

Is that so, or did I get the documentation wrong, or did I mess up in my calculations?

Is that so, or did I get the documentation wrong, or did I mess up in my calculations?

@JakobBD I am not sure I understand your calculation.

From briefly looking at it, why should
$\text{sqSectorAvrgShare}=\sum_{i=1}^n (s_i-\bar{s_i})^2=\sum_{i=1}^n (s_i-\frac{1}{n})^2$
hold?

Anyway, I think here is a numeric example that shows that the two differ by more than a fix offset:

if the deviation of the sector-specific bioliq share from the overall average bioliq share is 0, and similarly for fos, and syn, then the squared differences from the sector values to the average values will always be 0.

however, the sum of the squared shares will be very different if you are in a situation with all bio/fos/syn-shares = 0.33 (where it would be number_sectors * 3 * 0.33^2, so number_sectors * 0.326) and a situation where bio and fos shares are 0 and syn-share is 1, where it would be number_sectors * 1^2 = number_sectors

@robertpietzcker nevermind, I messed up:
The averaging obviously isn't done over the SE types $i$, but over the sectors $j$. So $\sum_{i=1}^n s_{i,j}=1$, but $\sum_{j=1}^n s_{i,j}\neq1$.

But that might raise a different. more severe issue (if I'm not messing up again):

The penalty sqSectorShare not only penalizes unequal distribution over sectors, but also unequal overall shares of SE types.
I.e. a scenario with 100% fossil in all sectors would get a higher penalty than a scenario with 1/3 fos/bio/syn in all sectors.

So in the fossil-dominated world we live in, syn and bio would get a push with no founding.

Is that an effect we want from that penalty switch?

The penalty sqSectorShare not only penalizes unequal distribution over sectors, but also unequal overall shares of SE types.

yes, which is one of the reasons I prefer the (currently default) "sqSectorAvrgShare " :-)

but you are right, some info about this should be added in the description of "sqSectorShare" - like "this method ALSO creates an unwanted incentive for the model to have equal fos/syn/bio shares"

which is one of the reasons I prefer the (currently default) "sqSectorAvrgShare " :-)

To me, that seems like the only difference to sqSectorAvrgShare.

I.e.: sqSectorShare can be shown to be sqSectorAverageShare plus a penalty on unequal overall SE shares.

You're saying this only difference is unwanted (and I agree).

Which begs the questions: Is there any advantage to it? If not, then I'd be in favour of deleting it.

(As always, if I'm not messing up).

Calculations:

$\bar{s_i} = \frac{1}{n_j} \sum_j s_{ij}$

and then

$\sum_{i,j} (s_{i,j}-\bar{s_i})^2$

$= \sum_{i,j} (s_{i,j}^2- 2 s_{i,j} \bar{s_i} + \bar{s_i}^2) $

$= \sum_{i,j} s_{i,j}^2 - 2 \sum_{i} \bar{s_i} \sum_{j} s_{i,j} + \sum_{i,j} \bar{s_i}^2$

$= \sum_{i,j} s_{i,j}^2 - 2 n_j \sum_{i} \bar{s_i}^2 + n_j \sum_{i} \bar{s_i}^2 $

$= \sum_{i,j} s_{i,j}^2 - n_j \sum_{j} \bar{s_i}$

some info about this should be added in the description of "sqSectorShare"

39c2641

Which begs the questions: Is there any advantage to it? If not, then I'd be in favour of deleting it.

The alternative formulations are present to compare different levels of complexity and allow runtime comparisons.

The default option selected considers the pros and cons observed so far about these alternatives, but as these formulations should be further improved in subsequent PRs, I prefer to keep the current options in the code.